1. Field
The present invention relates generally to the activation of logic resident on a computing device, and more specifically, to the activation of core applications resident on computing devices.
2. Background
System Designs
Advances in technology have resulted in smaller and more powerful personal computing devices. For example, there currently exist a variety of portable wireless devices, such as portable wireless telephones, personal digital assistants (PDAs), and paging devices that are each small, lightweight, and can be easily carried by users. Typically, these devices are severely resource constrained. For example, the screen size, amount of available memory and file system space, amount of input and output capabilities and processing capability may be each limited by the small size of the device. Because of such severe resource constraints, it is often typically desirable, for example, to maintain a limited size and quantity of applications residing on such devices. Certain constrained resources, such as memory and/or file system space, are often the driving resource constraints that prompt such design choices. However, even when such resource constraints exist and there exists a corresponding demand to limit the size and quantity of applications on such computing devices, it is not uncommon to also find a co-existing demand for certain “preloaded” applications, including core applications.
“Preloaded” applications are applications that have been loaded on a computing device before such computing devices have been delivered the end users. “Core” applications are typically those applications and/or engines that are generally known to have certain characteristics including, for example, those applications and/or engines that are known or expected to be frequently called by other applications and/or those applications and/or engines that perform critical functionality. For example, for certain computing devices in certain circumstances, a multimedia application engine is known to be an application engine that is frequently called by a number of applications, and as such, such multimedia engine it is sometimes preloaded on certain computing devices as a core application. If this application was not preloaded on the computing device prior to delivery, the often used aspect of the application and/or engine, in certain circumstances, would almost certainly require a subsequent interactive downloading, over a network, of the application and/or engine post-delivery—an interactive/post-delivery procedure that could have been avoided with an initial preload.
Typically, the preloading of applications is performed by entities such as an Original Equipment Manufacturer (OEM) or by an Application Specific Integrated Circuit (ASIC) manufacturer. In one example, an OEM directly preloads one or more core applications on such devices at the OEM's manufacturing facility. In another example, OEMs indirectly provide core applications where the OEM includes ASIC chips, already preloaded with one or more core applications at the ASIC manufacturer's facility, into a final computing device. As described, the actions of at least two types of entities, OEMs and ASIC chip manufacturers, can individually, separately or together, result in the preloading of applications on computing devices.
Core applications are currently known to be selectively preloaded in both activated and an inactivated states. The “activated state” denotes an application that is configured to be called, and to execute when called. In contrast, the “inactivated state” denotes an application that is not presently configured to be either called, or to execute when called. For example, currently, some manufacturers (ASIC or computing device OEMs) sometimes include in their product (i.e., IC chips & computing devices) an application that is optionally available to the end user. Typically, such optional applications do not include core applications. Further, such optional applications are provided by the manufacturers in either an inactivated state or activated state. Further, regardless of the state that the application is provided, the application typically forever remains in such state, and therefore, for example, the manufacturer is generally not known to change the activated/inactivated state once the computing device has been delivered to the end user. In operation, currently, preloaded inactivated applications sometimes initially appear to be active applications to the user, i.e., display as an active selection on a user interface, and such applications may be selected by a user, (either directly or indirectly), and in response, the computing device displays a message indicating that an error was encountered in attempting to execute such application.
A corresponding aspect to this supplying of preloaded inactivated applications by manufacturers is that such manufacturers are able to realize variable pricing based on the active functionality available within the product at the time of delivery. Manufacturers are able to charge higher prices for products containing activated preloaded applications than products that are either totally absent such applications or have such preloaded applications inactivated prior to delivery. As such, a manufacturer, for example, can use a tiering strategy where the manufacturer either excludes the application from the device or provides the device with such application in an inactive state to allow the device to be sold at a lower price to lower-end markets. However, because the functionality available at the time of delivery remains the same functionality over the life of the product, once a particular preloaded inactivated application is delivered in an inactivated state the functionality associated with such application is forever dormant, and any associated potential revenue associated with such functionality is typically forever lost.
Many computing devices, including wireless computing devices, are capable of interactively downloading applications over a network, including a wireless network. Unlike the preloaded applications that are typically preloaded in a controlled environment, (e.g., while under the control of the manufacturer), such interactively loaded applications are loaded in a relatively uncontrolled environment that gives rise to the need to utilize certain authentication and authorization methods to assure system integrity and to police authorized usage. One common approach of providing such authentication and authorization is to adopt the use of digitally signed licenses. Digital signing of applications and components prevents those components from being modified. This digital signature can also provide other benefits such as providing linkage back to the original developer, protecting license data, etc.
A specific example of a system that provides for the interactive download of applications are those currently publicly available versions of the Binary Runtime Environment for Wireless® (BREW®) software platform developed by Qualcomm, Inc., of San Diego, Calif. BREW® is generally known to be a thin veneer over a telephone's operating system, which, among other features, often provides interfaces to hardware features particularly found on personal wireless devices. BREW® is also provided at a relatively low cost with respect to demands on device resources and with respect to the price paid by consumers for computing devices containing the software platform.
Other features of BREW® include its end-to-end software distribution platform that provides a variety of benefits for wireless service operators, software developers and computing device consumers. The BREW® end-to-end software distribution platform includes logic distributed over a server-client architecture, where the server performs, for example, billing and application distribution functionality, and the client performs, for example, application execution and user interface functionality. One aspect of BREW® is its functionality that provides to a user an environment where a user can selectively identify and selectively purchase an application for execution on the user computing device where a selected application is wirelessly downloaded to the computing device in response to the actions of the user. Such functionality includes the generation of a cost amount that appears on a subsequent phone bill of the user. As such, BREW® contains functionality that handles all the billing, security, and payments to desired entities, where, for example, BREW® directs payments to the appropriate entities associated with the consumer transaction, such as payments to the wireless service operators and to the corresponding software developers.
Although certain applications may be typically considered as required “core” applications by many different computing devices, some applications, otherwise considered as required core by many computing devices, may not be considered a required core application by other particular computing devices. What may be considered a required core application can depend on a wide variety of factors, including, but not limited to, device architecture, the types of operator provided applications, user desired applications and preferences, and the like. As a result, a particular core application may be present on a particular computing device but may never in fact actually executed by such computing device. Such non-used/non-required core applications waste valuable resources by further constraining the already severely resource constrained environment by unnecessarily consuming additional resources. This situation is particularly acute where the core application at issue is large in size.
OEM/ASIC Revenue Models
Typically, when ASIC manufacturers provide ASIC chips to OEMs, the ASIC manufacturers receive only a one time initial revenue payment amount (corresponding to a revenue receivable and a corresponding revenue payable) for the associated chips (and the functionality thereon) from the OEMs. This includes ASIC chips that include preloaded core applications. Currently ASIC manufacturers have little ability to generate revenue payments beyond the initial one time initial revenue payment amount since the ASIC chips generally contain all the active functionality that they will ever contain at time of delivery. Although an ASIC manufacturer may be able to modify the type of functionality available on the ASIC chip immediately prior its delivery, this does not change the fact that such manufacturers revenue is typically tied directly to the one set of active functionality available at the time of delivery. Because the preloaded active functionality available on the chip typically remains static once delivered, the ASIC manufacturer is therefore only currently capable of receiving the one time revenue payment related to such ASIC chip. Therefore, because of the static nature of the functionality provided by ASIC manufacturers, such ASIC manufacturers are precluded any additional revenue beyond the single one time revenue payment for each of their shipped ASIC chips.
Similarly, when OEMs provide computing devices to consumers, OEMs typically only receive a one time initial revenue payment (associated with a revenue receivable and a corresponding revenue payable) for the associated computing devices (and the functionality thereon). This includes computing devices that include preloaded core applications. Currently OEMs have little ability to generate revenue payments beyond the initial one time initial revenue payment amount since the computing devices generally contain all the active functionality they will ever contain at the time of delivery. Although an OEM may be able to load additional applications on the device immediately prior to its delivery, this does not change the fact that such manufacturer's revenue is tied directly to the one set of active functionality available at the time of delivery. Because the preloaded active functionality available on the computing device remains static once delivered, the OEM is therefore only currently capable of receiving the one time revenue payment related to the computing device. Therefore, because of the static nature of the functionality provided by the OEMs, such OEMs are precluded any additional revenue beyond the single one time revenue payment for each of their shipped computing devices.
There is therefore a need in the art for the ability to preload core applications in an inactive mode. With the introduction of the ability to preload inactivated core applications also comes a need in the art for the ability to activate such preloaded inactivated core applications. Also, with the introduction of the ability to preloaded inactivated core applications also comes a need to remotely activate such preloaded inactivated core applications. Also, with the introduction of the ability to preloaded inactivated core applications also comes a need to hide the presence of such applications prior to their activation. There is therefore also a need in the art to provide the ability for OEMs and ASIC manufacturers to realize revenue receivables after an initial sale of a product by providing the ability to activate dormant functionality in such products after the delivery of such products. There is also a need in the art to provide 3rd parties, such as OEMs and ASIC manufacturers the ability to track usage of core applications after delivery of computing devices to an end user. There is therefore also a need in the art to selectively provide core applications without having to preload different sets of core applications for different users. There is also a need in the art to limit overall system activity by requiring computing devices, rather than server devices, to initiate requests to activate additional core application functionality on such computing devices.